One backend for MDriven systems is the relational database. We use OCL (Object Constraints Language) and the databases use SQL. We do objects but databases do data. We bridge the gap with object-relational-mapping strategies or OR-mapping for short.
We allow you – the developer – to express your query in OCL (or Linq, if you are in code) and translate this to SQL which fetches the data that builds up the objects.
Normally, OCL expressions work with lazy fetch. Whenever you access relations that are not yet fetched from DB, MDriven fetches them – silently – possibly in the background in the AsyncThread, if you use the IAsyncSupportService to always have an accessible UI (recommended for WPF, WinForms, and fat client strategies).
It is also possible to use the OCL-PS (PS for Persistence Storage, i.e. the database in this case). When doing so, the navigation of links does not lazy fetch data; instead, the expression is interpreted and translated to SQL. SQL is sent to the persistence storage for execution. This execution returns the identities for the objects in the result of the expression. MDriven then uses the standard fetch operations in those identities to resolve them to objects.
This is how the multilevel search logic in MDriven ViewModels works (described further here).
For a couple of different reasons – all made apparent in this article – we have chosen to further enhance the way the OCLPs service can be used in ViewModels.
PSExpressions are typically used when the amount of objects seen by the expression is large – maybe more than a few 100 or 1000. PSExpressions, however, may also be used when you – the developer – want to do things that are easy in SQL but hard or unwise in OCL – like finding 1 object in a table of millions – or performing sum, count, max, min or average operations on vast amounts of data in your database.
This article explains how to do this inside the MDriven Framework (you can always access your own database).
The News
1. The OCLPsService has a method called GetValue. This can be used to return data from the database and not merely object keys as the execute method does.
2. To facilitate exposure of database functions, a new OCL operator has been introduced: SqlPassthrough(somesqlasastring,type1ofdataback,type2ofdataback, etc).
3. The OCLPsHandle will get the return type of the expression and choose either Execute or GetValue to do the right thing.
4. The ViewModel columns have a new property called IsPSExpression – this will be true if a column starts with the name “PSExpression_.”
5. The ViewModel variable, "selfVM," that we described here, has been extended with 2 new methods: ExecutePS and PSExpression_Refresh. The ExecutePS (viewmodelclass,viewmodelcolumn) will take arguments to a ViewModel column and execute the expression found there with OCLPs service. It will return the list – whether it is tuples of data or objects. The PSExpression_Refresh() will find all IsPSExpression columns and execute their expression in OCLPs.
6. The ViewModelWPFUserControl and VMClass have been extended to fulfill these new obligations.
Having these things in place makes it possible to do things such as this:
In the image above, the action at #1 calls the selfvm.PSExpression_Refresh(), which will make the two PSExpressions evaluate in the database. Since the expression at #2 contains an sqlpassthrough operator the provided SQL will execute in the DB. The result is expected to be two integers. These two integers are displayed by the #3 ViewModel class.
The result is shown in the executing application. In the grid named “Thing,” we see the sum and max of all attribute2 in the class1 that are bigger than vNewVar that we have assigned the value 3 in this case.
Doing this without the need for instantiating any of the involved Class1 objects is a good thing.
Making assumptions about how your database looks is a bad thing, but the tradeoff is acceptable whenever you get large volumes in your MDriven systems.